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Föreläsning 1 


e Kursinformation. 
e Utvecklingsprocessen. 
e Kravspecifikation. 


e Gruppindelning. 
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Kursansvarig: Christer Carlsson 


Gästföreläsare: Joachim von Hacht 
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Handledare: Michal Andreen 
Staffan Björnesö 
Christer Carlsson 
Peter Evensen 


Daniel Wetterbro 


Kursens māl 


Kursen skall ge er erfarenhet av att utveckla ett mindre 
programsystem i grupp, med användande av en föreskriven 
utvecklingsprocess. 


Kursen skall också ge tillfälle att utnyttja (och därmed 
konsolidera) kunskaper från tidigare kurser i objektorienterad 
programutveckling samt människa-datorintraktion. 


Ett outtalat syfte är också att ni skall ha kul under projeket. 
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Undervisning 


Fórelásningar: 
Måndag 16/3, kl 10-12 i sal HA2 
Mándag 23/8, kl 8-10 i sal HA2 
Fredag 27/3, kl 13-15 i sal HA2 
Tisdag 31/8 kl 13-15 I sal HC2 


Grupphandledning: 


Torsdagar i lāsveckorna 1-4 samt 6-7, enligt sárskilt schema. | 
lāsvecka 5 och 8 beslutar varje grupp om handledningstid i 
Overenskommelse med sin handledare. 


Nārvaro ār obligatorisk under handledningstimmarna. 


о 


Aterkoppling: 
Återkoppling ges på gruppens producerade dokument och kod. 


Deadlines 


Māndag 16/3: Sammansāttningen av projektgrupperna skall vara klart 
Onsdag 18/3: Valet av projekt skall vara klart (senast kl 9.00) 

Fredag 20/3: Kravspecifikation skall vara klar (senast vid midnatt). 
Fredag 27/3: Designdokumentet skall vara klart (senast vid midnatt). 


Onsdag 13/5: En första version av projektrapporten skall vara klar 
(senast vid midnatt). 


Tisdag 19/5: Demoversion av programmet skall visas för handledaren. 
Tisdag 19/5: Dokument och kod skall vara opponentgruppen tillhanda. 


Tisdag 26/5: Projekten redovisas, all dokumentation och kod skall vara 
klar. 


Examination 


Betyg: 
Endast betygen godkānd och underkānd ges. 


Krav för godkänt: 


* Aktivt deltagande i gruppens arbete inklusive produktion av kod 
och obligatoriska dokument. 


e Närvaro vid och aktivt deltagande under handledningstimmarna. 
Veckans arbetsinsats redovisas gruppvis skriftligen till 
handledaren. 


* Närvaro vid och aktivt deltagande i presentationsdagen 26 maj 
(presentation och opposition). 
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Tidsplan 
Lāsvecka Utvecklingsfas Resultat 
1 Kravinsamling Kravspecifikation 
2 Analys och design Designdokument 
3-7 Implementation Fungerande program, 
manual 
8 Rapportering Rapport, presentation, 


demonstration 
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Gruppindelning 


Mālsāttningen ār exakt fyra medlemmar per grupp. Om inte 
antalet deltagare pā kursen ār jāmt delbart med fyra kommer 
nāgra grupper att fā tre medlemmar. 


Gruppindelningen skall bli klar i dag. 


Resten av veckan 
| dag: Gruppindelning. 
Tisdag: Val av projekt. 


Torsdag: 


Fredag: 


Meddela Christer via e-post senast kl 9.00 på onsdag. Ange 
gruppnummer, projektval samt namn, personnummer och 
Chalmers CID för samtliga medlemmar). 


Handledarmöte (se kurshemsidan för tid och plats). 
Utkast till kravspecifikation. 


Skriftlig kravspecifikation per e-post till handledaren. 
Denna och alla andra dokument skall skrivas pā engelska. 


ET 
Projektförslag 


Varje grupp skall välja ett av nedanstående förslag (mer information 
om förslagen finns på kurshemsidan). 


Implementationssprāk skall i samtliga fall vara Java. 


Korsordseditor. 
Sudokueditor. 


Bibliotekssystem. 


Simulering av övergångsställe. 


System för Lunch Dating. 


Datorspel. Val av spel måste godkännas av handledaren. 


Eget förslag. Måste presenteras skriftligt för och godkännas av 
handledaren. 


SEE 
Risker vid mjukvaruutveckling 


* Misslyckas med att möta användarnas behov 
Gör inte det användaren vill att det ska göra. 


* Misslyckas med att förutsäga kostnader 
Programsystemet blir dyrare att utveckla än förväntat. 


* Misslyckas med att nå deadlines 
Är inte färdigt i tid. 

* Prestandaproblem 
Är slött. 


* Portabilitetsproblem 
Gār inte att flytta till en annan maskin med lātthet. 


e Underhallsproblem 
Har otydlig struktur och innehāller komplicerd och svārtolkad kod. 


* Tillfórlitlighetsproblem 
Innehåller buggar som gör att det kraschar. 


* Anvándargránssnittsproblem 
Svārt att anvānda, trist layout. 


Aktiviteter vid programutveckling 


Utveckling av ett större programsystem innehåller åtminstone 
följande aktiviteter: 

* Insamlande och dokumentation av användarkrav. 

* Analys av kraven. 

* Design av program och GUI. 

* Kodning. 

* Enhetstester (tester av enskilda klasser). 


* Integrationstest. 


Hur skall dessa utfóras och dokumenteras? 


Utvecklingsprocesser 


Nāgra omtalade modeller: 


* Waterfall model (1970-talet) 
Föregående fas avslutas innan nästa fas påbörjas. 
Övertagen från annan ingenjörsvetenskap. 


* Iterative development (1980-talet) 
Systemet byggs i flera iterationer med utökad funktionalitet. 


* Agile development (2000-talet) 


Iterativ process med korta iterationer (som längst ett par veckor) 
och fokus på tät samverkan i utvecklingsgrupp. 
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Waterfall model (vattenfalls modellen) 
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Iterative development 


Requirements | Analysis & Design 


Implementation 


Deployment 


Evaluation 


Testing 





(SEI 
Agile development 


Agile development (lättrörlig utveckling) ar ett synsätt gemensamt for en 
grupp av utvecklingsmetoder. Det ar alltsa inte en utvecklingsmetodik i 
sig utan snarare en uppsättning värderingar, attityder och principer. 


Agile värdesätter: 
* Individer och samspel framför specifika metoder, processer och verktyg. 
e Körbar programvara framför omfattande dokumentation. 
e Kundsamarbete framför kontraktsförhandlingar. 
е Anpassning till förändring framför att följa en statisk plan. 
Bland lättrörliga metoder kan nämnas: Adaptive Software Development, 


Crystal, DSDM, Extreme Programming (XP) och Lean Software 
Development. 
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Vār process 


* Kravbeskrivning (3 dagar). 
Enkel form av anvāndningsfall (use cases). 


e Analys och design (1 vecka). 
Design av GUI enligt MDI-kursen. 
Mer om design av programstrukturer nästa föreläsning. 


* Implementation (4 veckor). 
I huvudsak en iteration med tillägg om tid medger. 
Enhetstest av viktiga klasser. 


Forbjudet!! 
Cowboy coding: Var och en hackar dar han/hon kanner for det. 
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Börja inte koda nu 


Många finner det frestande att börja koda direkt, dvs: 


* utan att ordentligt gjort klart för sig vilka krav och 
önskemål kunden har, 


* utan att tänka igenom en design för programmet. 


Varför skulle det gå bättre vid programutveckling än inom 
annan ingenjörsverksamhet. 
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Dilbert om kravspecifikation 
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MaA 
1. As Management 2. As Specified in the 


Requested It Project Request 


T 


А Ж XS 
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Senior Analyst The Programmers 


= x 


ДОХА 
5. As Installed 6. What The User Wanted 





es отпос 
Vad är ett krav? 


Ett krav är en funktion eller egenskap som systemet skall tillhandahålla för att 
uppfylla sitt syfte. 


Funktionella krav 


Specificerar de handlingar som systemet skall kunna utföra. 


Icke-funktionella krav 
Specificerar egenskaper hos systemet t.ex. användbarhet, tillförlitlighet, 


prestanda, modifierbarhet och återanvändbarhet. 
Nivāer av krav 
Tvingande — absolut nödvändiga för att systemet skall uppfylla sin uppgift. 


Onskvārda — går att klara sig utan, men detta kan leda till vissa besvär eller 
lägre effektivitet. 


Trevliga att ha — bidrar endast marginellt till systemet som helhet. 
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Krav 


Ett krav skall: 
` specificera VAD, inte HUR 
` vara korrekt 
* vara komplett 
` vara otvetydigt 
` vara kortfattat 
* vara design oberoende 
* vara uppnābart 


* vara testbart 
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Anvāndningsfall (use cases) 


Systemets funktionella krav fångas med anvandarfall (use cases). 
Anvándningsfall är en mall för en sekvens av interaktioner 
(scenarior) mellan en aktör (användare) och ett system 
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Anvandarkrav 


Användningsfall (use cases) 


Ett användarfall beskriver vilken interaktion en aktör har med systemet 
för att uppnå sitt mål. 


En fullständig beskrivning av ett användarfall innebär ofta många steg 
av interaktion, med flera alternativ och felsituationer. 


Vi nöjer oss med att i första skedet beskriva huvudalternativet i några 
få meningar. Säg i detta skede så lite som möjligt om 
anvāndargrānssnittet. 


Vi anger för varje anvandarfall dess prioritet och tidsåtgång. 


Observera 
Vi beskriver ett användarfall enbart med text. 


Det finns grafiska standarder för att beskriva användarfall; skall dock 
inte användas i kursen. 


USE 
Ett exempel 


Vi tänker oss ett system för att boka och sälja biljetter till en 
biograf med flera salonger. 
Fóljande skall gālla for systemet: 


* systemadministratórer kan lägga in föreställningar i 
systemet 


* säljare kan boka och sälja biljetter 


* ekonomisystemet kan få information om sålda biljetter. 


Låt oss betrakta några anvándningsfall. 


Anvāndningsfall 1 
Lāgg till en film 


Aktör: Systemadministrator. 
Mal: Lägg till en film och dess föreställningar till systemet. 
Interaktion: 


е Användaren anmodas att ge filmens namn och premiärdatum. 


е Systemet visar en grafisk vy med tillgängliga visningstider för de 
olika salongerna den kommande månaden. 


e Användaren väljer ett antal av dessa alternativ. 


e Systemet bekräftar och lagrar valen. 
Prioritet: 1. 


Svårighet: Lätt. 
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Anvandningsfall 2 


Salja biljetter 
Aktor: Sāljare. 
Mal: Salja ett antal biljetter till en viss forestallning. 
Interaktion: 


e Användaren anger en film. 


е Systemet visar en grafisk vy av salongen for nästa föreställning med 
lediga och upptagna platser markerade. 


е Användaren kan markera ett antal lediga platser och sälja dem. 
Prioritet: 1. 


Svårighet: Lätt. 


SEE 
Anvandningstall 3 


Biljettforsāljning Over internet 
Aktör: Kund vid dator med internetanslutning. 
Mål: Köpa biljetter till en viss föreställning. 
Interaktion: 


е Användaren anger en biograf och film. 


e Systemet visar en grafisk vy av salongen för nästa föreställning med 
lediga och upptagna platser markerade. 


e Användaren kan markera ett antal lediga platser och köpa dem och 
betala med kontokort. 


Prioritet: 3. 


Svårighet: Svår. 


Kravspecifikation som kontrakt 


Den godkānda kravspecifikationen fungerar som kontrakt 
mellan er och kunden/handledaren. 


Anvándarfall av prioritet 1 och 2 skall implementeras. 


Omprövning kan eventuellt ske i lāsvecka 5, om det visar sig 
nödvändigt. 


Hur hitta kraven 


Ett stort problem 


Vi har ingen riktig kund. 


Handledaren får fungera som ersättare, men kan inte ta 
kundens roll på riktigt. 


Förslag till arbetsmetod: 


* Brainstorming (hela gruppen), för att komma på/förstå vad 
man skall kunna göra med programmet. 


* Sortera kraven i viktiga/mindre viktiga samt lātta/svāra. 
e Skriva användningsfall. 


En kravspecifikation denna vecka 


1. Introduction 
An overview of the document. 


2. Scope 
A brief description of the product to be developed. 


3. Functional Reguirements 
A list of all the use cases (priority 1-3). 


4. Other Reguirements. 


Time requirements? Security requirements? Data volume 
requirement? Etc. 


5. User interface sketch. 
Do not put too much effort into producing the sketch. 


